_______________________________________________________________________________

FutureNET Network Protocol Specifications                              07/24/92

Written by Joshua M. Thompson
Copyright (c) 1992 Frontier Technologies, Inc.
_______________________________________________________________________________

I. Preface

This document describes the protocols required to support a connection to the
FutureNET network.  It will be of use primarily to authors of bulletin board
software who wish to allow their software to connect to the FutureNET network,
or who wish to create an interface between the FutureNET and another network.
However, those wishing to know the inner operation of the FutureNET will also
find this document valuable.

This document is free and may be distributed freely provided it is distributed
in its entirety without alteration, and no fee is charged for it other than a
reasonable disk copying fee (for user groups and such). Any other use of this
document without the express written consent of Frontier Technologies, Inc. is
strictly prohibited.

II. Joining the FutureNET

Currently there is no fee charged for connecting a system to the FutureNET, and
none is planned in the forseeable future.  Access to the network is open to any
site capable of connecting to it, provided that site does not cause damage to
the network or its members.  Authors of FutureNET-compatible software must make
sure their software is fully compatible and does not damage the network in any
way (by losing data, garbling data, etc).

III. Technical Overview

Conceptually, the FutureNET network model is based on the seven layer ISO-OSI
Reference Model.  Such a layered approach simplifies software developent and
testing, and allows individual layers to be modified or upgraded without
affecting software at the other layers.

The layers of the FutureNET are as follows:

	1. Physical Layer

	   The physical layer of the FutureNET defines the actual
	   hardware used to link the sites together, along with the low-level
	   software that provides access to the hardware.  For most sites,
	   this will consist of a Hayes-compatible modem connected to
	   a serial I/O port, coupled with appropriate modem and port drivers.

	2. Data Link Layer

	   The data link layer is responsible for providing a standard
	   way of accessing the physical layer hardware.  The data link
	   layer of the FutureNET is defined by the Link Access Protocol
	   or LAP, which provides for the sending/receiving of data in
	   packets.  For modem connections the link protocol used is the
	   Modem Link Access Protocol ("MLAP").

	   The data link layer provides for network addressing using 16-bit
	   site ID numbers.  Every site on a network must have its own
	   unique site ID number, meaning a single network is limited to
	   65,535 sites (ID number 0 is invalid).

	   Unlike most networks, the data link layer of the FutureNET is
	   also responsible for the reliable delivery of data.  In
	   particular, data written to the link at one end is guaranteed
	   to arrive at the other end in the same order and without errors.
	   It was decided to place this function here because most data
	   links will be over modems using reliable file transfer protocols
	   such as Ymodem or Zmodem.  In addition, since modem connections
	   are not available on demand, the data link layers will generally
	   be using a store-and-forward approach in which the ordering of
	   data packets is preserved.

	3. Network Layer

	   The network layer of the FutureNET provides for the construction
	   of internets.  It does so by adding a 16-bit Network number to the
	   16-bit site IDs provided by the data link layer, thus expanding the
	   address range of the FutureNET to a full 32 bits.

	   To efficiently handle traffic between multiple networks, the network
	   layer defines GATEWAYS and INTERNET ROUTERS.  Both are special sites
	   capable of passing data between two or more separate networks.

	4. Transport Layer

	   The transport layer provides three primary functions.  First, it
	   arbitrates the use of the network layer by its clients.  Secondly,
	   it provides a set of services for dealing with network routing
	   information (such as the expansion of partial routes into full
	   routes).  And finally, the transport layer provides a naming service
	   whereby descriptive names may be assigned to network addresses and
	   client IDs.

	5. Session Layer

	   The primary purpose of the session layer is to provide for the
	   creation of network sessions by client applications.

	   A session provides a sort of direct connection, called a VIRTUAL
	   CIRCUIT, between a local client and an entity at a remote site.
	   The entities at either end of the VC can transmit and receive data
	   over the network much more easily, because the programs don't have
	   to worry about specifying details such as routing information.
	   Instead, the session itself fills in these details from information
	   provided by the client(s) when the session was first opened (these
	   parameters can be modified at any time without having to re-create
	   the session).

	   Another important network service added by the session layer is
	   stream-based network access.  Put simply, stream based access
	   allows programs to read from or write to the network on a byte-
	   by-byte basis, as opposed to datagrams or LAP packets.  Stream-
	   based service is useful when the size of the data being written
	   is not known.

	6. Presentation Layer

	   The software at the presentation layer is responsible for receiving
	   incoming data and presenting it to application layer programs in a
	   more usable format.  Examples of presentation layer programs include
	   the Electronic Mail Manager and the Conferencing Manager.

	7. Application Layer

	   The application layer comprises all user-level programs running on
	   the network.  These include electronic mail programs, conferencing
	   systems, networked games, and so on.

IV. The Physical Layer

As indicated above, the physical layer is comprised of the actual hardware
used to link sites and its associated drivers.  The specifications of this
later are not defined by FutureNET because of the close relationship between
the physical layer and the data link layer.

V. The Data Link Layer

	A. The LAP Manager

                1. Purpose

The LAP Manager component of the network is responsible for keeping track of
various Link Access Protocols (LAPs) installed and what network or networks are
accessible via each LAP.

		2. Data link layer requirements

Any implementation of a FutureNET data link layer must meet several
requirements:

	1. The maximum packet size of 4 Gb (4 byte size) must be supported.
	   This very large value was was chosen to facilitate backward
	   compatibility with FutureNET Phase I [implemented as MLAP] which
	   could transmit packets of this size.

	2. Packets must arrive at their destination in the same order as they
	   were sent, without omissions, duplications, or errors.

	3. The data link must be able to understand standard 16-bit FutureNET
	   site IDs.  If the underlying physical layer uses a different
	   numbering scheme, then the data link layer implementation will have
	   to translate between hardware IDs and FutureNET IDs.

	4. If the data link layer is not a broadcast network, then it must
	   understand enough about the topology of the network to be able to
	   reach any desired site, even if that site is not reachable by a
	   direct connection.  MLAP is a good example; it provides routing
	   through intermediate sites to sites not directly connected to
	   itself.

	5. Multiple simultaneous destinations must be supported for a single
	   packet.  If true multiple destinations are absolutely impossible on
	   the underlying physical link, then the protocol will have to "fake"
	   them by sending multiple copies of such packets.

	B. The Modem Link Access Protocol

The most common data link protocol is the Modem Link Access Protocol or MLAP,
which provides the five services mentioned above over standard dialup modem
connections.

The MLAP protocol definition is divided into two parts.  The first part is the
connection protocol, which describes the chain of events executed by two
MLAP sites to initiate a connection and exchange spooled network data.
The second part is the storage format used by the protocols to store network
packets on disk until they can be transmitted during a connection.

		1. The MLAP connection protocol

The MLAP connection protocol is based on the X/Y/Zmodem protocol suite.  Ymodem
is used to exchange an initial set of identification files (containing data
such as network site IDs and passwords).  Once both sites have successfully
transmitted their ID files, the actual network data is transmitted, first by
the caller, and then by the host.  The protocol used for this data transfer
is selected automatically as the best available to both caller and host.

The following is a detailed description of the MLAP connection protocol.

	 1. The caller dials the phone number of the desired host site.

	    If the system answers, go to step 2.

	    If the number does not answer, or some other error occurs
	    (such as a VOICE result code), the connection is aborted.

	     If the number is busy, the caller tries again later.  The
	     number of redials allowed, and the time between redials,
	     are configured by the administrator of the calling site.

	 2. The caller goes into a ten second loop waiting for something
	    to be received from the host (any data will do).

	    If something is received, go to step 3.

	    If the timer expires, go to step 3 anyway.

	 3. The caller goes into a fifteen second loop.  In this loop,
	    a space followed by a control-x is transmitted once per
	    second.  This is done to abort any long logon screens, bypass
	    FV's initial emulation scan, and answer any logon questions
	    regarding graphics and whatnot.

	    When the timer expires, to go step 4.

	 4. The caller transmits the sequence control-x, control-\ (back-
	    slash), control-^, %%%% (four percent symbols), and a
	    control-M.  The first three control characters will clear out
	    METAL's input buffer and clear the current input line (this
	    clears any spaces left from step 3).  The four percent
	    symbols and the carriage return tell the host to enter its
	    MLAP host module and attempt to initiate a connection.

	    Note that althought four percent symbols are transmitted, the
	    receiver should trigger its host on reception of any number of
	    perecent signs.  Future Vision simply checks the first character
	    of the input line and calls the host if that character is a "%".

	    Go to step 5.

	 5. The caller goes into a five second loop waiting for a "$" to
	    be received from the host (indicating the host is ready to
	    begin).

	    If the "$" is received, go to step 6.

	    If the timer expires, assume a "$" and go to step 6 anyway.

	 6. The caller attempts to transmit its MLAP identification
	    file using ymodem batch protocol (the formats of the ID
	    files are documented below).

	    If the transfer fails, hang up and abort the attempt.

	    If the transfer succeeds, go to step 7.

	 7. The host will attempt to transmit a similar ID packet
	    back to the caller, again, using ymodem batch.

	    If the transfer fails, hang up and abort the attempt.

	    If the transfer succeeds, but the error code in the
	    packet is nonzero (host reports error), hang up and
	    abort the attempt.

	    If the transfer succeeds with no host error, go to step 8

	 8. The caller should examine the received packet to obtain
	    the new password assigned to it by the host.  The host
	    generates a new random 32-character password for each
	    successful MLAP linkup.  The password is passed back in
	    the host's ID file, and must be saved for use in the next
	    linkup attempt.

	    Go to step 9.

	 9. If the caller has any data waiting for the host, then the
	    data is sent now.  The protocol used is the best protocol
	    available at both sender and receiver, and can be
	    determined by examining the features flags in the host's
	    ID packet.

	    If the transfer fails, go to step 10.

	    If the transfer suceeds, delete the spooled data and go
	    to step 10.

	10. If the host has any data waiting (determined by looking
	    at the host's ID file), and sendback has been enabled by
	    the caller, then the host will attempt to send its spooled
	    data now.  The protocol is the same one used in step 9.

	    Go to step 11.

	11. The connection is now over; both sites hang up the modem.

	    Go to step 12.

	12. If the transfer in step 10 was successful, the received
	    data is uncompressed (if needed), and processed.  This
	    includes transferring the packets to the LAP Manager so
	    that they can be sent to their respective listeners.

	    **END OF CONNECTION

For an MLAP host program, the sequence of events to execute for an
incoming connection attempt can be easily inferred from the above
outline.

		2. MLAP Identification File Format

The format of the identification file for the MLAP protocol is as follows:

  +0 : Network identification string.  This string is used to 	       32 bytes
       identify a valid network ID file.  The current value of the
       string is "FutureNET%FV30^NeTwOrK_VaLiD!!!!".

 +32 : Caller's password.  The caller passes the host its call-in      32 bytes
       password in this field, and it must match the password
       expected by the host.  If there is no match, an error is
       returned; otherwise, the host generates a new, random 32-
       character password and returns it to the caller in this
       field.  This means that a given password is never valid
       for more than one successful network connection.

 +64 : Site ID number of the caller.  The host uses this value to       2 bytes
       determine which site is calling in.  The host echos this value
       in its reply file.

 +66 : Site ID number of the host.  The caller sets this value          2 bytes
       to the ID of the host it thinks it is connecting with.  If
       the host senses that the caller is calling the wrong site, it
       will return an error code.  The host echos this value in its
       reply file.

 +68 : Unused and reserved.  This area should be filled with zeros     60 bytes

+128 : Features word.  This field is composed of 16 individual bits     2 bytes
       that describe the features available at the site.  Currently,
       the following bits are defined:

	 bit 0 = Zmodem available (1 = Yes, 0 = No)
	 bit 1 = Ymodem-G available (1 = Yes, 0 = No)
	 bit 2 = Ymodem-4K available (1 = Yes, 0 = No)
	bit 15 = *Site is Phase II compliant (1 = Yes, 0 = No)

       All other bits are reserved and should be set to zero.
       A "*" indicates bits not defined by Phase I protocol.  These
       bits will be set to zero by P1 sites, and their values
       will be ignored by P1 sites.

+130 : Sendback flag.  In the caller's ID file, this flag must be       2 bytes
       nonzero if the host is allowed to send any of its spooled
       data during this connection.  If it is zero, the host will
       not send anything, even if there is data waiting.  This can
       be used to divide the network costs between two sites, by
       having each site call the other site and transfer one-way.

+132 : Size of data in bytes.  If this is zero, then the site has       4 bytes
       no spooled data waiting.  Also, if the sendback flag is
       zero, then the host will return zero in this field regardless
       of how much data is waiting.

+136 : Unused and reserved.  Set to zero for future compatibility     122 bytes

+254 : Error flag.  If this field is nonzero, then the host has         2 bytes
       detected an error in the network linkup attempt, and the
       caller should hang up (the caller does not use this field
       and must set it to zero).  Currently, the following error
       codes are defined:

	1 = Bad ID file.  The file sent by the caller
            had invalid values in one or more fields.
	2 = Wrong host.  The ID of the host does not match that
            specified by the caller in the host ID field of its
            identification file.
	3 = [unused and reserved]
	4 = [unused and reserved]
	5 = Unknown ID.  The caller's ID number is not recognized
            by the host.
	6 = Bad password.  The caller's password does not match that
            expected by the host.

		4. MLAP storage format

File consists of zero or more network packets in a linked list.  Each packet
consists of a header followed by zero or more bytes of data.  The header format
is as follows:

  +0 : Pointer to header of next block in file.  If this is		4 bytes
       the last block in the file, then this will point to the
       End-Of-File (EOF) position.
  +4 : Number of bytes of network data following the header.		4 bytes
       This value may be zero.
  +8 : Site ID of the system that sent this block			2 bytes
 +10 : For Phase I blocks, this is the user number associated		2 bytes
       with this block or zero if there is none.  For Phase II
       packets this is a flags word (see below).
 +12 : Channel number for this block.  If this value is zero,		2 bytes
       then this block has been read and can be deleted.
 +14 : Channel subtype.  This is for use by the program which		4 bytes
       sent the data.  For example, this is used to hold the
       conference number for conferencing messages.
 +18 : Number of entries in the destinations list			2 bytes
 +20 : Destination list.  See below for format				x bytes

The Channel Number and Channel SubType fields are outdated fields used by the
older Phase I sites to determine which program at the destination is to receive
the packet.  The defined values are as follows:

		$0000 = [used to signal a deleted block; do not use!]
		$0001 = Electronic Mail
		$0002 = Conferencing
		$0003 = Remote File Manager
		$0004 = System Update Manager
		$0005 - $7FFF = Reserved for system use
		$8000 - $FFFF = Free for third-party use

To distinguish phase 1 packets from phase 2 packets, a special set of values
are used.  These values are a channel number of $5032 and a channel subtype
value of $D0B2xxxx, where xxxx is a two-byte LAP client ID number (see below).
This is a guaranteed-unique signature as true Phase I sites use only the low
three bytes of the channel subtype and always leave the fourth byte zeroed.

LAP client ID numbers are two-byte values describing which higher-layer client
is to receive the packet.  Currently, the following values are defined:

		$0000 = Reserved
		$0001 = MLAP Command
	$0003 - $00FF = Reserved for LAP control packets.
		$0100 = FutureNET Datagram Protocol client data packet
		$0101 = FutureNET Datagram Protocol control packet
	$0102 - $FEFF = Reserved; contact Frontier Technologies for
			an assignment in this range.
	$FF00 - $FFFF = Free for experimental use, but should not be
			used in final versions of products.

If the packet _is_ a phase II packet (indicated by the special channel type and
channel subtype fields mentioned above), then the two bytes at +10 are
interpreted as a flags word.  The format of this word is as follows:

	bits 0-15 : Reserved; set to zeroes for future compatibility

The destination list describes which sites on the network are to receive the
packet.  It consists of one or more entries in the following format:

	+0 : Site ID of destination.  If this is nonzero, then
	     this is the only data and this entry is only two
	     bytes long.  If it is zero (which is normally an
	     invalid site ID), then this is a custom routing
	     entry and the optional fields described below are
	     present).

	(These fields are present only if [+0] is zero)

	+2 : Number of site IDs in custom routing path.  Must be
	     at least 2, and not more than 255.  This is reasonable
	     since the net generally can perform one hop of the route
	     per day, and a 255 hop route would take nearly a year
	     to complete.
	+4 : List of [+2] two-byte entries.  The entries describe
	     the exact path this packet should take, site by site.
	     The first site _MUST_ be the source site, and the last
	     site _MUST_ be the final destination (hence the minimum
	     value of 2 for [+2])

If a custom routing chain is specified, it must be a complete route
beginning at the source and ending at the destination.  No gaps are allowed
in the route and any two adjacent sites IDs in the path must be connected.

For all destinations specified without a custom route, MLAP figures out the
route using a standard least-cost/shortest-length algorithm.  This type of
routing is distributed, meaning each site is responsible for knowing only
which site is the "next hop" for the packet.  The advantage to this is that
the network automatically re-routes any data in transit if the network map
changes.  Custom routes, on the other hand, will fail if the map changes and
a necessary link disappears.

		5. MLAP Routing File Format

The MLAP protocol uses a standard format for storing routing information. These
files are the MAP.xxxx and ROUTES.xxx files, where xxxx is the four-digit
hexadecimal network ID number.

			a. Structure of MAP.xxxx files

The map files contain global routing information for an entire network.  It is
divided into 256-byte records, each record corresponds to one site on the
network.  These records in turn are divided into sixteen 16-byte subrecords.
Each subrecord describes on network connection between the site corresponding
to the record and another site.  Therefore each site can connect to at most
sixteen others.

The format of the subrecords is as follows:

 +0 : Destination site ID for this link 				2 bytes
 +2 : Cost of this link in 100ths of a cent per kilobyte		4 bytes
 +6 : Length of this link in 10ths of a kilometer			4 bytes
+10 : Speed of this link in bytes per second				2 bytes
+12 : Reserved								4 bytes

Map updates can be performed at the record or subrecord level and are
transmitted via a LAP Map Update packet (see section 6, MLAP Control Packets).

			b. Structure of ROUTES.xxxx files

The ROUTES files contain the information necessary to route a packet to any
other site on the network.  A ROUTES file is specific to a single site and is
derived from the data in the MAP files.

The exact method used to obtain the shortest routes is irrelevant, so long as
the algorithm generates the total cost and length of the route, and the ID of
the next site along that route.

The routing file contains 16 byte records.  Each record contains the necessary
information to route packets to one site.  The structure of these records is as
follows:

 +0 : ID of next hop site in shortest route to this site.  All data	2 bytes
      for this site is sent to this site ID.  if this ID is zero,
      then the site is unreachable.
 +2 : Number of hops required to reach this destination.  Must be	2 bytes
      at least one.
 +4 : Cost to reach this site in 100ths of a cent per kilobyte		4 bytes
 +8 : Length of route to this site in 10ths of a kilometer		4 bytes
+12 : Speed of this link in bytes per second.				2 bytes
+14 : Route flags.  This is a bitmapped value as follows:		2 bytes

		bit 0 : Route is custom (0 = No, 1 = Yes).  This
			flag is always cleared by the automatic
			route generator but will be set if the
			route is modified by a LAP control packet.
	    bits 1-15 : Reserved; set to zeros.

As can be seen from this routing file structure, MLAP routing is distributed.
Each site knows only the next hop destination to a given site.

		6. MLAP Control Packets

The LAP Manager reserves to LAP control packet types for use by MLAP.  These
VI. The Network Layer

	A. Definitions

To send/receive packets on an internet, the network layer defines its own
network packets called DATAGRAMS.  Datagrams are similar to LAP data packets
(and in fact are transmitted and received via LAP packets), but provide the
extra information needed to address sites on an internet.  The protocol that
defines the format of datagrams is called the FutureNET Datagram Protocol, or
FDP.

FDP is responsible for forwarding datagrams between the necessary gateways and
routers to get it to its destination network.  Once the packet reaches the
destination network, that network's link access protocol(s) perform the task of
getting the packet to the desired destination site.

	B. FDP Packet Format

FDP packets consist of a small header followed by zero or more bytes of client
data.  They are bundled inside of LAP packets using special client IDs.  These
IDs are $0100 for FDP data packets, and $0101 for FDP control packets (control
packets are not currently implemented).

The header format for FDP packets is as follows:

  +0 : Size of packet header in bytes.  This value can also be		4 bytes
       thought of as the offset in bytes from the beginning of the
       header to the client data.
  +4 : Source address.  This field contains the ID (site number         4 bytes
       and network number) of the site which sent this datagram.
  +8 : Client ID.  This two-byte field determines which higher-         2 bytes
       layer client sent this datagram, and therefore which client
       at the receiver is to receive the datagram.
 +10 : Datagram flags.  Currently unused; set to zeroes 		4 bytes
 +14 : Size of the client data in bytes.  Since FDP packets ride        4 bytes
       inside of LAP packets, the total size of this block (header
       plus data) cannot exceed 4 gigabytes.
 +18 : Number of descriptors in the routing list.			2 bytes
 +20 : Routing list.  This list consists of [+18] variable-		x bytes
       length entries.  See below for format.
 +xx : Client data, up to 4,294,967,296-xx bytes			x bytes

The client ID field, like the LAP client ID field, is divided into several
subranges.  These currently defined subranges are as follows:

	$0000 - $00FF = Reserved for future system use.
		$0100 = Transport Manager client data packet
		$0101 = Transport Manager control packet.
		$0102 = Name Manager request packet.
		$0103 = Name Manager reply packet.
		$0104 = Electronic Mail Manager packet.
		$0105 = Conferencing Manager packet.
		$0106 = Remote Filing Manager packet.
		$0107 = System Update Manager packet.
	$0106 - $FEFF = Reserved; contact Frontier Technologies for an
			assignment in this range.
	$FF00 - $FFFF = Free for experimental use, but should not be
			used in final versions of products.

The Datagram Flags field is a longword (32-bit) value interpreted a series of
bitmapped flag fields.  At this time no fields are defined and the entire flag
field should be set to zero to maintain future compatibility.

The routing list field contains all routing information for this packet.  It
consists of one or more variable-length entries called Routing Descriptors.
Each RD describes the route for one intended destination for the datagram, and
has the following format:

	+0 : Route Descriptor Flags, bitmapped. 			2 bytes

		bits 0-15 : Reserved; set to zero.

	+2 : Number of nodes in routing list.				2 bytes
	+4 : Routing List.  This field consists of [+2] four-	   [+2]*4 bytes
	     byte entries.  Each entry is the full network
	     address (site ID followed by network ID) of one
	     destination in the route.

	     The route can be considered to be subdivided into
	     one or more SUBROUTES.  Each subroute is simply the
	     section of the full route that exists on one network.
	     When the net number changes, a new subroute has begun.

	     Subroute paths are passed directly to that network's
	     LAP protocols, so all rules for constructing LAP routes
	     apply.  In addition, FDP imposes the following additional
	     rules:

		1. A subroute must begin with the ID of the site where
		   the path enters that network.  For the very first
		   subroute this will be the originating site's ID; for
		   all others it will be the ID of an internet router.

		2. A subroute must end with the ID of the site where
		   the path leaves that network.  For the last subroute
		   this will be the destination site's ID; for all others
		   it will be the ID of an internet router.

		3. Where two subroutes join, the ending router of the first
		   must be equivalent to the beginning router of the second.
		   This simply means the route must enter the second network
		   by the same router as it used to leave the previous
		   network.

		4. In the case where a subroute should be autorouted through
		   its network, the path should contain two sites : the
		   beginning and ending router.  ANY subroutes of less than
		   three sites are assumed to be an autorouted.

		5. If you need to use a custom subroute and the custom route
		   is only two sites, insert a site in the middle with the
		   same net ID as the other two sites but with a site number
		   of $0000.  Site #0 is interpreted as a place holder and is
		   ignored in routing.

		6. To use full autorouting, specify just one subroute and
		   have it contain just one site, that site being the final
		   intended destination.  FDP will expand the route to include
		   the necessary routers.

	C. FutureNET Addresses

The added addressing range provided by FDP requires the defintion of a new
type of network address, the FutureNET ADDRESS, to describe a full 32-bit
internet address.  Compare this with a SITE ID, which is a 16-bit address
only valid on a single network.

VII. The Transport Layer

The transport layer consists of two distinct parts.  The first part is the
Transport Manager, which is responsible for arbitrating the use of FDP by network clients.  The second part is the Name Manager, a set of protocols and
routines to provide for the assignment of descriptive names to network
addresses.

	A. The Transport Manager

		1. Transport Manager IDs

The primary purpose of the Transport Manager is the to arbitrate the use of
FDP's rather limited client ID range.  This is accomplished by adding a small
header to the client data containing the source and destination program
addresses (specified as Transport Manager IDs) and then sending this
header/data combination in an FDP datagram.  Such datagrams will have a client
ID of $0100 (for TM data packets) or $0101 (TM control packets, which are not
currently implemented).

A Transport Manager data packet consists of an eight-byte header followed by
client data.  The header format is as follows:

	+0 : Source client ID.  This is the Transport Manager		4 bytes
	     ID of the program which sent this datagram.
	+4 : Destination client ID.  This is the TMID of the		4 bytes
	     program at the destination site that is to receive
	     this datagram.

A Transport Manger ID (TMID) is simply a four-byte integer assigned to a single
client application.  It should be noted that a given TMID is only valid on the
site where it was assigned.  Therefore, network applications making use of
TMIDs cannot assume that their peers will have the same or similar TMIDs.
Instead, such applications can find their peers on the network using the Naming
Manager (see part B).

With the addition of the Transport Manager, we must define a new type of
address, the FULL FutureNET ADDRESS, to describe the eight-byte combination
of a FutureNET Address and a TMID.  A FutureNET address can only specify a
single site on the internet, whereas a full FutureNET address can specify a
single application running on the internet.

		2. Routing management functions of the Transport Manager

The secondary purpose of the Transport Manager is to provide applications with
a standard set of route management functions, such as expanding partial routes
into the full routes required by FDP or the LAP protocols.

	B. The Naming Manager

The Naming Manager allows for the assignment of more descriptive names to the
somewhat cryptic combinations of numbers that make up site IDs, FutureNET
addresses, and full FutureNET addresses.

The Name Manager is functionally divided into two parts.  The first, the Local
Naming Manager, handles name requests using information stored locally.  The
LNM is used when an immediate result is desired, such as when a program wishes
to know the name of a given site.  Since the LNM operates purely with locally
available data, it is not covered in this document.

The second part of the Naming Manager is the Remote Naming Manager, which is
responsible for handling name requests involving other sites.  This includes
generating name requests and also responding to incoming requests from other
sites.  The RNM operates using a client-server model; incoming requests are
received by the Name Manager Server, which interprets the request, builds a
reply, and transmits the reply to the client.

A Naming Manager request packet is transmitted inside a datagram with a client
ID of $0102.  The packet structure consists of a header followed by zero or
more command requests.  The reply packet has a similar structure, but is
transmitted in a datagram with a client ID of $0103.  One reply packet is
generated for every request packet.

The structure of a request packet is as follows:

 +0 : Number of command requests.  May be zero. 			2 bytes
 +2 : Reserved; set to zeroes for future compatibility		       14 bytes
+16 : Start of command request records, if any.

A command request record has the following format:

 +0 : Command word. Valid commands are 0 (FindByName), 1 (FindByTag),	4 bytes
      2 (BindName), and 3 (UnbindName).
 +4 : Client Transaction ID.  The client should place a four-byte	4 bytes
      value in this field to distinguish it from other requests sent
      to this server recently.  The server echoes this value in the
      reply packet.

      NOTE : The server has no use for this field.  It is the sole
             responsibility of the client to generate and use this
             field.
 +8 : Entity Type; see below.						2 bytes
+10 : Entity name.  This is a 0-32 character string.  If the string    32 bytes
      is less than 32 characters, the remaining space should be
      filled with nulls ($00's)


VIII. The Session Layer

	A. The Session Manager

	B. FutureNET Data Stream Protocol

IX. The Presentation Layer

	A. The Format Manager

	B. The Electronic Mail Manager

	C. The Conference Manager

	D. The Remote Filing Manager

	E. The System Update Manager

X. The Application Layer
